Image credit: Flickr
“How do you say no to feature requests?”
If we had a shilling for every time we were asked that question, we’d have a lot of useless old money.
We use our own software to manage any feature requests, including the ones we say no to. We aren’t going to go as far as saying you can only do this with Receptive, but it makes it a darn sight easier.
Related: Building a SaaS product - it’s not a democracy
The TL:DR Version
Requests come in. We assess them and instantly turn some down for a number of reasons. Then we move the rest to an “Awaiting Feedback” status and, as the status suggests, wait for some feedback. Using that feedback, we can determine which features we should be building, and conversely, which we shouldn’t. Easy.
The Detailed Version
Our short version not good enough for you, eh? Fair enough.
We start by reviewing any requests that come to us. There are 5 key reasons why we might instantly reject one.
1. Lack Of Clarity
Sometimes a customer gets a little overexcited when submitting a feature request (come on, we’ve all been there) and fails to accurately explain what they’re trying to say.
In this instance, we ask for clarification and more detail. If, for whatever reason, they fail to provide us with the detail we need to properly understand the request, then we’ll have to say no.
Kinda like this:
“We have to decline this request as we didn’t get a specific enough use case or reasoning behind the request. If you would like this feature at any point in the future, please provide more feedback on what you’re trying to accomplish and why this is important to you so our product team can re-review.”
2. Conflict With Strategy
We have a pretty clear vision of where we’re headed, and a strong belief that what we’re doing is actually quite good. Often, a request may contrast with our strategy.
For example, we’re often asked to ramp up the complexity of managing feature requests. This goes against our strategy of easing the workload of product managers. So we have to say no.
A little like:
“I think we’re pretty committed to the want / don’t want binary choice. It’s not that “don’t want” is actually hindering a feature’s likelihood of being developed, it just tells Receptive not to asks the feature to the person that clicks.”
“Out of scope, we just don’t think that this is somewhere that we’re taking our product.”
3. Bugs
People often report bugs (not the bunny) in the form feature requests. Of course, this isn’t the time or place for bugs.
We add the issue to GitHub for further inspection, and then provide a simple explanation.
Something along the lines of:
“This is a bug, rather than a feature that we can build”
“This is either a bug or a specific browser weirdness, we’ll investigate as a bug.”
“This is a bug we’re investigating now.”
4. Already Existing Features
It’s possible that customers want a certain feature to solve a problem that can already be solved by an already existing feature.
In this case, we point them in the direction of help documentation or explain how they can use a certain feature to solve their problem.
Examples include:
“This has been released for a while now, in the browse view you can filter by tag”
“This feature exists, it might not be super-obvious how to do it though. Go to…”
“We’ve already implemented this functionality. Instructions on how to do this here: __”
“This feature already exists, you have to select the status again. Perhaps could submit a more specific request, but I’m going to decline this”
5. Duplicates
Every now and then we start seeing double (and not just on Friday evenings). Customers will sometimes post a feature request which is identical to another request.
It’s easy enough to merge these duplicates together with a little explanation.
Such as:
“Duplicate, I’m declining this as we’ve got this covered in another feature request: #123xxx”
Now that we have our initial review out of the way, we move the remaining features, those that have made the cut, to the “Awaiting Feedback” status. This is basically like Bootcamp on The X Factor.
After we’ve gathered enough feedback on the feature requests, we either accept them and advance them to “Planned”, or we have to tell them they won’t be making it through to the judges’ houses.
There are 4 main ways in which we say no to feature requests at this stage of proceedings.
I. Low Demand
If the people have spoken and they don’t really want a feature, then our hands our pretty much tied. It wouldn’t make sense for us to proceed any further.
We say:
“We don’t think there’s enough demand from our customers, and we’ve got to focus on where we can help the most customers.”
Or, sometimes, if it’s more subjective, we give our unique perspective on the feature, for example:
“The edit UI is on the left as the roadmap can be very wide, and so it overflows the screen on the right, which I think is the expected side. But I’m left-handed, so I could be biased.”
“I don’t like to force new tabs on people too often, I see it as a necessary evil on marketing sites etc but the back button works pretty good for this use case”
II. Edge Cases
It sounds like a derogatory term for madness but when confronted with an edge case, we explain that it’s not a common enough problem to warrant solving it.
We might put it like this:
“It’s quite an occasional activity, in my book” “Sounds like [alternative solution], so there doesn’t seem to be a good case for building this now.”
“Too much of an edge case”
III. Future Releases Solve The Problem
Sometimes the stars align and it just so happens that you’re already building something that will solve a customer’s problem. In this case we’re declining a feature but solving the problem.
One might venture:
“Going to decline this, as we’ve got a bunch of reporting improvements coming and they are going to give you much more detail about “why” a feature is getting ranked high/low in the reports.”
IV. Low Value, High Effort
As much as it pains us to admit it, we can’t build anything. Some features will just be way too complicated to build in terms of time and effort, for very little payoff. It doesn’t hurt to be honest, though.
Try this:
“I think this is a tricky one, for example what if the users haven’t been created at the time that the features are imported? We’d then have to later merge the user records together. Declining this.”
That’s basically how we say no to feature requests. It’s a tough job but somebody has to do it. Hopefully this will help that poor soul out.
That’ll be one shilling, please.
